HipHop Fatal error: Class undefined: Db

[alpha_one_x86]

Hello, how fix the error:

 

HipHop Fatal error: Class undefined: Db

When prestashop is used with hiphop?

 

The trace:

    #0 include(), called at [:0]
    #1 ReflectionClass::fetch_recur(), called at [:0]
    #2 ReflectionClass->getInfo(), called at [:0]
    #3 ReflectionClass->check(), called at [:0]
    #4 ReflectionClass->isAbstract(), called at [/var/www/prestashop/classes/Autoload.php:102]
    #5 Autoload->load(), called at [/var/www/prestashop/config/config.inc.php:65]
    #6 include(), called at [/var/www/prestashop/index.php:27]
    #0 at [:1]\n    #1 include(), called at [:0]\n    #2 ReflectionClass::fetch_recur(), called at [:0]\n    #3 ReflectionClass->getInfo(), called at [:0]\n    #4 ReflectionClass->check(), called at [:0]\n    #5 ReflectionClass->isAbstract(), called at [/var/www/prestas$
HipHop Fatal error: Class undefined: Db
    #0 at [:1]\n    #1 include(), called at [:0]\n    #2 ReflectionClass::fetch_recur(), called at [:0]\n    #3 ReflectionClass->getInfo(), called at [:0]\n    #4 ReflectionClass->check(), called at [:0]\n    #5 ReflectionClass->isAbstract(), called at [/var/www/prestas

Cheers,

Edited January 2, 2014 by alpha_one_x86 (see edit history)

[benjamin utterback]

Hello alpha one, I have not heard of hiphop for php being used with PrestaShop.

 

Maybe somebody else has some experience but I don't think it's been used at all for PrestaShop. 

[alpha_one_x86]

I have added the trace, the git version show an great compatibility with lot of other cms type.

[benjamin utterback]

I don't know of any person who has implemented this php engine into PrestaShop, you want to optimize your loading times? 

[alpha_one_x86]

Yes, because is more and more a mess into prestashop, it's very difficult to have page generation time on big but bussy server due to php time consumed. The other script are very better.

 

EDIT: bug due to eval() into the php code.

Edited January 2, 2014 by alpha_one_x86 (see edit history)

[benjamin utterback]

You are not able to edit the php.ini to optimize some server configurations? If you can, read this here http://www.prestashop.com/blog/en/php-ini-file/

 

If you can't I would seriously consider switching hosts, it's a big hassle to use extra scripts when they are not used often, probably for good reason. 

[alpha_one_x86]

Hello, it's not optimizing, just remove the hosting restriction.

I have try already some optimisation like opcode cache. The optimisation remain very little.

 

I have already the biggest offer at 500€/month. I have already writed optimisation guide for prestashop, yes disable useless module help. But the code remaing slow. Use xdebug to see the profile you will see where are the slow down. My unique way it's pass to hhvm for old/actual prestashop and hop of prestashop will be optimised.

The page generation time have 2 negative effect: bad impression on the visitor, more sensible to DDOS attack. I don't see normal use 500€/month server to have correct performance where other cms work well with same load on 30€/month server....

 

Hhvm have this limitation on prestashop: don't support de autoloader because it need static or semi static code (no eval() for example). Don't support most of the abstract base with not defined method.

 

Cheers,

[benjamin utterback]

That's a lot of money. 

 

I wonder if you install a base, fresh install of PrestaShop on your server, will it run faster? 

[alpha_one_x86]

No, slower because it's not optimised.

 

To speak on same base: fresh install of Prestashop have on my home computer (then very correct: core i7, 16GB of memory, SSD), page time around 100ms, that's mean 10 requests/s on one core. In comparison of my own php script (20000req/s) it's very slow. And my optimized php script is around 60000requests/s.

xdebug show very slow time is only into php (normal, the database is empty).

 

Here you have 2 not very old profiling:

http://www.first-world.info/wp-content/uploads/2012/06/profiling-of-prestashop.png

http://www.first-world.info/wp-content/uploads/2012/06/profiling-of-prestashop-tree.png

 

I'm sys admin of more than 10000+ french e-commerce, and at this scale it's too wast of money. An good resolution for 2014 can be optimize your product, because it's so bad too have correct product but with so poor performance.

The best way it's do like phoronix, track the performance and performance regression. The security and performance it's not extra part of an project. But need be included into the base.

[benjamin utterback]

Well, I spoke with HHVM and they say that PrestaShop is not on their roadmap to ensure compatibility. They ask you to report any issues you have to their repo here, https://github.com/facebook/hhvm/issues

 

I hope this helps. Thanks!

[selectshop.at]

As Benjamin told, the problem should be your host. We are using Prestashop since some years. The latest versions need a good host to run with good performance, but also one of our shops with about 10.000 products has a parse of 2-3 seconds. This shop uses also a huge quantity of extra tools which we know slow the site. But a load of 2-3 seconds for each page (with 300 categories, 10.000 products and also about 300 filteroptions)  is not really so tragic.

 

Can you please write here your server settings, or at least a performance protocol (webpagetest f. ex or link) for the page making problems ? Which loading time are you having ?

 

At least you should consider to host on a CDN if it is not possible to speed-up your server.

Edited January 6, 2014 by selectshop.at (see edit history)

[benjamin utterback]

Hi Alpha_one.... try this fix for the error you are having.

add,

if($classname == 'Db')
{
require($this->root_dir.$this->index[$classname.'Core']);
abstract class Db extends DbCore {}
return;
}

 

in the autoload class
at the beggining of Autoload::load() method

[alpha_one_x86]

Hello,

 

Benjamin Utterback: thanks for this tips, I will try that's. But to reply on you previous message, hhvm will never support dynamic code like eval, ... it's not problem of support but conception of prestashop blocked on hhvm (because it's statique code compilation, that's mean: no dynamique include, only statique include like require('toto.php'), no eval(), ...).

 

selectshop.at: the best method is:

http://www.phpjabbers.com/measuring-php-page-load-time-php17.html

but the http benckmark tools give the same result.

I use already cdn to offload few bit the server.

The server settings are php 5.5 with opcode cache, 120ms of page time generation, with just the demo product (config to test). What's exact settings do you want?

[Dh42]

You might contact his person off of GH and ask them what they have done, https://github.com/facebook/hhvm/issues/808

[benjamin utterback]

Try out that fix. If you have any errors, let us know here as well as on the github page that Dh42 posted.

 

We are interested in finding a way to make hhvm work with PrestaShop.

[alpha_one_x86]

The version of prestashop adapted for hhvm (I have not tested for now):

https://github.com/ellisium/PrestaShop

[Sheub]

Hi everybody, hi alpha_one

 

Being a C developper, I find it a very good idea to use hhvm to compile prestashop and improve performances...

 

I am not very familiar to hhvm yet, but I wanted to draw your attention to this: On the Wikipedia page of hhvm, it is written:

There is near full support for the entire 5.4 PHP language (including the create_function() and eval() functions.

Maybe this are new features that came since the begening of the year?.

 

Sheub

[ZiZuu]

Hello,

 

Benjamin Utterback: thanks for this tips, I will try that's. But to reply on you previous message, hhvm will never support dynamic code like eval, ... it's not problem of support but conception of prestashop blocked on hhvm (because it's statique code compilation, that's mean: no dynamique include, only statique include like require('toto.php'), no eval(), ...).

 

selectshop.at: the best method is:

http://www.phpjabbers.com/measuring-php-page-load-time-php17.html

but the http benckmark tools give the same result.

I use already cdn to offload few bit the server.

The server settings are php 5.5 with opcode cache, 120ms of page time generation, with just the demo product (config to test). What's exact settings do you want?

 

 

PS has big issues with its Cache ... we had very very big performances issue having implemented any sort of caching and optimization machanisms *and* we "solved" just disabling the latter "Cache" option in the performances tab (no APC, no fscache, absolutely no memcache) ... otherwise BO consumes a lot of CPU, latency is very high and so on

 

 

We have nice performances with no Cache, Smarty on, APC only for opcode, memcached for PHP sessions ... we are investigating on HHVM and we really want to implement it

 

 

PS very poor performances optimization is a fact .. and it should be a must to work in the direction of improve them .. a lot.

[alpha_one_x86]

Hi everybody, hi alpha_one

 

Being a C developper, I find it a very good idea to use hhvm to compile prestashop and improve performances...

 

I am not very familiar to hhvm yet, but I wanted to draw your attention to this: On the Wikipedia page of hhvm, it is written:

There is near full support for the entire 5.4 PHP language (including the create_function() and eval() functions.

Maybe this are new features that came since the begening of the year?.

 

Sheub

Maybe, but the dirty code nead be cleaned, optimised and adapted. Mostly the dynamique part converted into static php to improve the performance.

[benjamin utterback]

PS has big issues with its Cache ... we had very very big performances issue having implemented any sort of caching and optimization machanisms *and* we "solved" just disabling the latter "Cache" option in the performances tab (no APC, no fscache, absolutely no memcache) ... otherwise BO consumes a lot of CPU, latency is very high and so on

 

 

We have nice performances with no Cache, Smarty on, APC only for opcode, memcached for PHP sessions ... we are investigating on HHVM and we really want to implement it

 

 

PS very poor performances optimization is a fact .. and it should be a must to work in the direction of improve them .. a lot.

 

Hello! I will chime in here and say that we are working on improving cache issues that we've experienced in the past. It would be great to know what issues you encountered specifically so we can help better. Thanks!

[alpha_one_x86]

Hello! I will chime in here and say that we are working on improving cache issues that we've experienced in the past. It would be great to know what issues you encountered specifically so we can help better. Thanks!

Prestashop take in general more than 200ms in front office on correct hardware, then <5req/s by core, againts 5000 for php only, and 100 000 for static html... I speak about new and vanilla prestashop, ... (when I was tested in PS 1.5 and 1.6)

Edited August 1, 2014 by alpha_one_x86 (see edit history)

[ZiZuu]

Hello! I will chime in here and say that we are working on improving cache issues that we've experienced in the past. It would be great to know what issues you encountered specifically so we can help better. Thanks!

Hello .. just googling for "prestashop slow back office" return a lot of similar cases ..

 

We had tuned for performances our Wheezy VPS, set up CloudFlare only for a secondary domain only used for media (no CF for non media-related stuff), used memcached for PHP sessions, installed and tuned APC (only for opcode), tried APC, memcached, fscache as Cache backend, Percona Server replaces Mysql ..

 

The very best resulst are obtained only disabling every PS cache backend ...

 

 

As enabling both memcached or APC as Cache backend gives immediate performances issue (for example APC memory is rapidly fragmented) we think the issue is inside the CacheCore class ... the key-value system should have something wrong ... bringing every backend to extreme fragmentation and heavy performance issues in a short time after cache init ...

 

 

Moreover, we are now thinking of migrating from apache to nginx, but it would be nice if PS will produce its own nginx configuration (.htaccess counterpart) so we have just to include that file in the Vhost configuration ..

 

HHVM is the next step and having PS to support it would be very appreciated... we will produce pull requests or patches if we will be able to ..

Edited August 1, 2014 by ZiZuu (see edit history)

[alpha_one_x86]

I add note as C10k,C10M dev into hight performance. HHVM is just tip to improve the performance to minimizing the effect of slow code. But is just a work around, prestashop need real optimisation.

We have limit into compiler/interpreter to fix the bug and slowness of the application (wirth ley).

In similar case, other web application can handle millions of client on single server, with millions of query by seconds.

Use static page + html5 session/local storage can greatly improve the performance because the static part is instantanly returned, the client session part is loaded one time on webbrowser and never asked (or only on critical part).

But clearly be 100x more slow than pur php only is a deffect. Actually prestashop use 99% of the time into php, can't handle 10K of client, ... the exploitation cost is expensive, and you can profile your code to see where is slow (I was do that's: http://www.first-world.info/profiling-of-prestashop.html). And integrate a limit of slow down to do a release, and like phoronix do continous benchmarking to track the hurge performance regresion.

Edited August 1, 2014 by alpha_one_x86 (see edit history)

[ZiZuu]

Moreover, DB query are slow too ... performing mysqltuner gives a simple tip: "use indexes on JOIN query" ... it seems a very large number of expensive JOIN is performed without indexes .. and that's a pain

Edited August 4, 2014 by ZiZuu (see edit history)

[alpha_one_x86]

Moreover, DB query are slow too ... performing mysqltuner gives a simple tip: "use indexes on JOIN query" ... it seems a very large number of expensive JOIN is performed without indexes .. and that's a pain

In my case, I don't have database problem. And it's very easy to get the more slow query and add index directly into phpmyadmin.

[ZiZuu]

In my case, I don't have database problem. And it's very easy to get the more slow query and add index directly into phpmyadmin.

Never said it is difficult, but it is a task for PS developers, not for the system administrator implementing the shop ..

In order to keep DB performance good DB admin has to tune caches for high mem consumption .. same performances should be obtained optimizing DB queries, a priori, not filling RAM with DB caches (if the load would not require it otherwise)

[alpha_one_x86]

I re-express my thinks:

- actually on more than 2000 prestashop, 99% of time is consumed by php, not mysql

- mysql it's just index put, no more, do into few minute, by admin or PS dev, but yes it's important

- php re-forge code, and totale remake to have decent performance it's long term task, but very important

[ZiZuu]

Ok, I can subscribe

 

I totally agree PS is really too PHP-side resources consuming ... and it is a fact not being "excused" by the tasks it has to achieve, it has to be refactored with performances in mind, not only maintainability or readability

[alpha_one_x86]

And when the server 48 cores ARM will be released, or any very parallele cpu, the power by thread is very less, but in general very more (GPGPU?). Prestashop what it will responds? It's normal page generating time of 10s or more? Welcome into the internet of 90' years!

[benjamin utterback]

And when the server 48 cores ARM will be released, or any very parallele cpu, the power by thread is very less, but in general very more (GPGPU?). Prestashop what it will responds? It's normal page generating time of 10s or more? Welcome into the internet of 90' years!

 

Hey, it's not normal to have that slow loading time. What would you like us to do? What's a good mix of complex code and powerful features, along with fast speed and clean loading time? 

[alpha_one_x86]

Hey, it's not normal to have that slow loading time. What would you like us to do? What's a good mix of complex code and powerful features, along with fast speed and clean loading time? 

Continuous bench-marking (track the regression), code with keep in mind the performance, fast path for the front office. You have all the info on internet, I can to help you personnally by skype/gtalk/jabber (I speak only french and spanish).

Start with the noob link: http://www.phpjabbers.com/measuring-php-page-load-time-php17.html + xdebug profiling google to finish on expert link. Be power full feature not excuse the slow down. For example, don't load all lib, use static code, execute the minimal amount of code, ... look what is executed, if is usefull, if can be skipped, the cache need be very more fast than data processing, ...

Basically the front office is only replace some variables and do few php condition. You can too like here:

http://www.calle-hardware.com/

Externalize the dynamic part (ajax), taking care of the async of the js to have very good render and impression on the visitor, included when the php part is slow or connexion is slow.

Lof of stuff, most is not done into prestashop.

Note: prestashop is multi-page site, take care of size downloaded for normal navigation, not only full page, ... you will see the CCC grouping can be un-productive.

Edited August 5, 2014 by alpha_one_x86 (see edit history)

[ZiZuu]

Hey, it's not normal to have that slow loading time. What would you like us to do? What's a good mix of complex code and powerful features, along with fast speed and clean loading time?

No it is not normal .. if you really think it is, nothing will be never improved ...

 

We are not spiting in the plate we have lunch, but there a serious performances problems in PS that are NOT due to the tasks it has to perform.

 

The lack of a working, efficient, caching system is an aspect. But there a performance-critical sections of PHP code in PS that can and should be refactored with performances in mind ... I saw pieces of code with nested loops of loops, allocating memory and memory, abusing the output buffer and so on ...

 

It really can be improved in the PHP code side, *then* refined with caching at different levels, *then then* optimized at DB/FS/CDN levels

 

 

IF performances in PHP coding is a "must" a faster application is achievable; if, on the other hand, we still think that performances just CAN'T be improved because the app is huge, overloaded by features, and so on then never and never could be faster than now ...

 

 

Hope developing team could just give a look to the plea of their audience, made of PHP programmers too ... they can be a resource

 

 

Thanks

[Sheub]

 

Hope developing team could just give a look to the plea of their audience, made of PHP programmers too ... they can be a resource

 

 

Thanks

 

Why don't you just start right now then? I am sure the developpoing team will be happy to get your help and concrete suggestions on how to improve the performances...

[ZiZuu]

Because we are an e-commerce with programming skills (and there are a number of our patches into the PS code too) but our business is to sell, not to code PHP ..

Edited August 6, 2014 by ZiZuu (see edit history)

[xavriley]

Just wanted to add to this that a site I work (www.forsyths.co.uk) with also had horrible performance when using APC cache (PS 1.5.1) and worked much better when switched off. Horrible fragmentation etc. although it worked great for the first 5 minutes while the cache wasn't full.

 

Also, I had the experience of code I'd written being a terrible bottleneck (recursive category query) - make sure you rule that out before calling Prestashop slow!

 

I will try to dig through our Git history and see what the exact issues were. We have 100k+ products and Prestashop performs reasonably well. Happy to discuss over twitter - I'm @xavriley

[alpha_one_x86]

Why don't you just start right now then? I am sure the developpoing team will be happy to get your help and concrete suggestions on how to improve the performances...

Because maintain fork is very hard, mostly in this case because the change is deep. After if you do power full code, but prestashop do slow code, the result will be slow code + fast code = slow code.

To learn the PS dev need learn to optimise and know where is their own error, where is the critical part, when need huge take care and where less.

It's like one dev do bug fix, and 5 dev introduce bug... always the software will be with bug. It's better one dev do bug fix, and the ( dev take care of bug because it fix the bug too, but not at full time.