corrupt db table ps_guest

[Havouza]

I have found a corrupt db table, ps_guest. It contains 2596906 rows. What is this?

Result when try to recover

Wrong bytesec:   0-  0-  0 at   54229816; Skipped

Can the table be emptied

[datakick]

It can be emptied.

You might experience some strange behaviour with existing orders / abandoned carts / stats, but nothing serious.

 

[Havouza]

I am trying to find why the shop is so slow. this could be one reason to it. The other shop has only 10% of the rows and is also much faster. It seems that the table only holds statistics

[datakick]

It is used not only for statistics, but as a peristent identifier of your annonymous visitors.

Every time your visitors acces your site (with the same cookie), the session will be assigned with the same Guest record.

This can be used for various pusposes. For example, my revws module uses this functionality to allow annonymous visitors to edit their own reviews.

If you truncate this table, your visitors will receive brand new Guest record on the next visit, and the (persistent) identity is lost. 

[Mediacom87]

Hi,

This table is part of the tables that can quickly slow down a ThirtyBees store, that's why I developed a module to clean this kind of table and even automatically regularly.

 

[Havouza]

Hi @Mediacom87

I will ask the owner. But unfotunately I think the problem is bigger. He has 2 shops, mostly identical. Same version, same number of products, about 1500 in each, same modules etc. They both resides on the same vps. Jv74.se is horribly slow, jv80.se is much better even if not perfect. I have run out of ideas about what can be wrong. The biggest delay is to load the frontpage. Both shops has memcached installed can you give a hint where to look

[Mediacom87]

This data, as previously explained, is generated with each new visit to your site by an Internet user, so it is that you have more visits on a store compared to the other store.

1 hour ago, datakick said:

Every time your visitors acces your site (with the same cookie), the session will be assigned with the same Guest record.

 

[musicmaster]

If this table had 2.5 million records quite likely some other statistics tables were too big too. Look at ps_connections, ps_connections_source and ps_pagenotfound. 

Prestools has a cleanup page with the most common operations. 

With tables this big you might also consider truncating them when they aren't used. It will be much quicker.

As Datakick mentioned these are statistics. But not everyone uses statistics or they use Google's tracking instead.